12장. 소프트웨어 설계의 프랙털 기하학

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 공식: https://www.jpub.kr/

한 줄 요약 — 소프트웨어도 살아있는 네트워크 기반 시스템이다. 복잡성은 초선형적으로 폭발하고 인지 한계는 정적이므로, 성장 한계를 넘는 유일한 현실적 해법은 새로운 추상화 도입이며, 이 원리는 메서드·클래스·모듈·서비스 모든 층에 프랙털처럼 자기 유사적으로 반복된다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 네트워크 기반 시스템의 세 속성(공간 채우기·불변 단말 장치·최적화)을 소프트웨어에 대응시켜 설명한다.
• 준선형·선형·초선형 성장 역학을 구분하고 소프트웨어 복잡성이 왜 초선형적으로 폭발하는지 분석한다.
• 프랙털 기하학의 자기 유사성 개념을 소프트웨어 설계에 적용한다.
• 균형 잡힌 결합 원리가 메서드→클래스→모듈→서비스 모든 층에 동일하게 반복됨을 설명한다.
• 성장 한계를 극복하는 두 종류의 혁신(재료 교체·형태 변경)을 구분하고 소프트웨어에 대응시킨다.
• 통합 강도와 거리가 상대적임을 층 간 예시로 설명한다.

전체 흐름도

[ 소프트웨어는 작게 시작하고 성장한다 ]
        │
        ▼
[ 네트워크 기반 시스템 — 혈관계·도시·소프트웨어 공통 ]
  속성 1. 공간 채우기 — 에너지(지식)가 모든 구성요소에 도달
  속성 2. 불변 단말 장치 — 기계 코드·하드웨어는 시스템 크기와 무관
  속성 3. 최적화 — 인터페이스 설계로 지식 흐름 최적화
        │
        ▼
[ 성장 역학 — 측면마다 속도가 다르다 ]
  ┌──────────────────────────────────────────────┐
  │ 기능        → 선형 (Linear)    증가           │
  │ 지식        → 준선형(Sublinear) 증가 ← 재활용 │
  │ 복잡성(상호작용) → 초선형(Superlinear) 증가   │ ← 위험
  │ 인지 한계   → 정적 (성장 없음)               │ ← 병목
  └──────────────────────────────────────────────┘
        │
        ▼
[ 성장 한계: 복잡성 > 인지 한계 → "큰 진흙덩이" ]
        │
        ▼
[ 갈릴레오의 두 혁신 방안 ]
  ① 더 강한 재료 — 소프트웨어: AI (아직 미도달)
  ② 형태 변경 — 소프트웨어: 새로운 추상화 도입 ← 현실적 해법
        │
        ▼
[ 프랙털 기하학 — 자기 유사성 ]
  자연: 나무 가지, 잎맥, 은하, 해안선 모두 같은 패턴 반복
        │
        ▼
[ 프랙털 모듈성 = 균형 잡힌 결합이 모든 추상화 층에 반복 ]

  시스템 간 ↕ 모듈 간 ↕ 클래스 간 ↕ 메서드 간 ↕ 문장(if 분기) 사이
  ──────── 어느 층이든 같은 결합 원리 ────────

0. 사전 필수 용어

1. 소프트웨어도 살아있는 시스템이다

소프트웨어는 처음부터 완성형으로 태어나지 않는다. 유기체·기업·도시처럼 작게 시작해서 성장한다. 성장 방식을 이해하면 왜 어느 순간 코드베이스가 통제 불가능해지는지, 그리고 어떻게 막을 수 있는지 보인다.

비유 1 — 나무의 가지

나무를 위에서 내려다보자. 굵은 줄기에서 가지가 뻗고, 그 가지에서 잔가지가 뻗고, 잔가지에서 또 가지가 뻗는다. 어느 가지든 가까이 당겨 보면 줄기와 같은 구조다. 이것이 자기 유사성. 소프트웨어 모듈 구조도 같다 — 시스템→서비스→모듈→클래스→메서드, 어느 층이든 같은 분기 원리로 구성된다.

비유 2 — 해안선

해변에서 멀리 보면 굴곡이 보인다. 가까이 가면? 같은 굴곡 패턴이 더 작은 규모로 반복된다. 더 가까이 가면 또 반복. 소프트웨어의 결합 복잡성도 마찬가지 — 어느 층을 들여다봐도 같은 결합 문제가 등장한다.

비유 3 — 만델브로 집합

만델브로 집합은 간단한 수식(z = z² + c)의 반복으로 만들어진다. 어느 부분을 아무리 확대해도 전체와 닮은 패턴이 나온다. 소프트웨어도 같다 — 균형 잡힌 결합이라는 단순한 원리 하나를 반복 적용하면, 모든 층에서 자기 유사적으로 올바른 설계가 나온다.

비유 4 — 우주의 은하 분포

우주 전체 지도를 보면 은하가 필라멘트 구조로 이어져 있다. 그 필라멘트를 확대하면 또 필라멘트. 자연이 선택한 복잡성 관리 방법이 프랙털이다. 소프트웨어의 계층적 모듈 구조는 자연이 검증한 이 방식의 소프트웨어판이다.

2. 네트워크 기반 시스템과 소프트웨어

제프리 웨스트 교수의 연구에 따르면 혈관계·도시·기업 같은 네트워크 기반 시스템은 세 가지 공통 속성을 가진다.

소프트웨어에서 "에너지"는 지식이다. 지식이 흐르는 "파이프"는 모듈 사이의 인터페이스다. 균형 잡힌 결합 맥락에서 지식의 깊이는 통합 강도로, 지식의 경로는 거리로 표현된다.

잘못된 예 — 에너지(지식) 흐름 막힘

# 잘못된 예: UserReportService가 User 전체를 받아 내부 필드를 직접 탐색
# → 지식이 "파이프(인터페이스)"를 통하지 않고 내부를 침입
class UserReportService:
    def generate(self, user: User):
        # user._internal_profile_data 직접 접근
        return f"{user._internal_profile_data['segment']} 리포트"

# 올바른 예: 필요한 지식(segment)만 공개 인터페이스로 전달
class UserReportService:
    def generate(self, user_segment: str):
        return f"{user_segment} 리포트"

3. 성장의 역학 — 왜 큰 것이 더 효율적인가

네트워크 기반 시스템의 모든 측면이 같은 비율로 성장하지는 않는다.

도시 규모 2배 시: - 주유소 수: 85% 증가 (준선형 — 공유 경제, Kuhnert et al. 2006) - 사회적 상호작용: 2배 이상 증가 (초선형 — 네트워크 효과, West 2018)

동물 비교: - 비글은 퍼그보다 2배 무겁지만 칼로리는 75%만 더 필요 (준선형)

성장 역학 시각화

      Y (결과)
      │  b. 초선형 (상호작용 수, 사회적 생산성)
      │ /
      │/ a. 선형 (기능 수, 주유소)
      /
     /c. 준선형 (칼로리, 지식 — 점점 완만)
    /
   └──────────────── X (입력: 시스템 크기)

a = 선형:   y = x        (1:1 비례)
b = 초선형: y = x^1.x   (위험 구간)
c = 준선형: y = x^0.x   (규모의 경제)

이것이 큰 시스템이 유리한 이유다. 기능은 선형으로, 지식은 준선형으로만 늘어나기 때문에 기존 지식을 재활용하며 더 많은 기능을 추가할 수 있다.

4. 성장 한계 — 갈릴레오의 경고

4.1 갈릴레오의 들보 실험

갈릴레오(『새로운 두 과학』, 1638)는 들보 크기를 2배 늘리면: - 무게: 8배 증가 (세 차원 모두 2배 = 2³) - 파괴 저항력: 4배 증가 (단면적 = 두 차원만 = 2²)

무게 증가 속도 > 저항력 증가 속도 → 결국 자체 무게에 무너진다.

"하늘 높이 솟은 말이 없는 이유": 뼈의 저항력이 무게를 따라가지 못한다.

4.2 소프트웨어의 갈릴레오 법칙

구성요소가 늘면 상호작용 수는 초선형적으로 증가한다: 공식 = n*(n-1)/2

구성요소  가능한 상호작용
  3개   →   3개 연결
  5개   →  10개 연결    ← 2배 구성요소 시 3.3배 상호작용
  7개   →  21개 연결
 10개   →  45개 연결    ← 2배 구성요소 시 4.5배 상호작용
 14개   →  91개 연결

그런데 인간의 인지 능력은 정적이다. 어느 순간 복잡성이 인지 한계를 넘으면 — "큰 진흙덩이"가 된다.

성장 역학 전체 그림

        ▲
복잡성   │   ╔═╗ 복잡성 (초선형)
        │  ╔╝ ║
        │ ╔╝  ║ 기능 (선형)
인지    │╔╝   ║
한계선  │╚════╝ 지식 (준선형)
        │─────── 인지 한계선 (정적)
        └──────────────────→ 시스템 크기

5. 혁신 — 성장 한계를 돌파하는 법

갈릴레오는 성장 한계를 극복하는 두 방법을 제시했다.

① 더 강한 재료 사용 소프트웨어에서는 인간 인지보다 복잡성을 더 잘 처리하는 AI. 현재 아직 미도달.

② 형태 변경 소프트웨어에서는 새로운 추상화 도입. 이것이 현실적 해법이다.

엘리야후 골드랫(Goldratt 2005): "기술은 최소한 하나의 제한을 줄이는 경우에만 이점을 가져올 수 있다."

비유 — 사자와 집고양이

사자와 집고양이는 기본 골격 설계가 놀라울 정도로 유사하다. 다만 사자는 뼈가 더 두껍고 조밀하다 — 더 큰 몸을 위해 "형태"를 조정한 것이다. 같은 설계 원리, 다른 규모. 소프트웨어도 같다 — 클래스→모듈→서비스로 커질수록 같은 추상화 원리가 "형태만" 조정되어 반복된다.

역사 — 도시의 혁신

소프트웨어도 같다 — 모놀리스 한계 도달 → 추상화(네임스페이스·모듈) → 마이크로서비스로 형태를 혁신해 성장 한계를 넓혀 왔다.

WolfDesk 예제 — 형태 혁신의 실제

WolfDesk v1 (10개 객체 모두 같은 네임스페이스):
┌────────────────────────────────────────────────────┐
│ 지원사례  부서  고객  우선순위  에이전트  제품       │
│ 사용자  상태  역할  권한                            │
│              (관련 없는 객체들이 뒤섞임)            │
└────────────────────────────────────────────────────┘
→ 기능 2배 추가 시 복잡성 폭발 예상 (n*(n-1)/2 효과)

WolfDesk v2 (4개 모듈로 추상화 계층 도입):
┌──────────────────┐  ┌──────────────────────┐
│ CaseManagement   │  │ IdentityAndAccess     │
│ 지원사례 일정    │  │ 사용자 역할 권한      │
│ 상태 제품 고객   │  │ (신원·액세스 담당)    │
└──────────────────┘  └──────────────────────┘
┌──────────────────┐  ┌──────────────────────┐
│ Distribution     │  │ Billing               │
│ 에이전트 할당    │  │ 청구서 구독플랜       │
│ 일정 분배 치명도 │  │ 청구주기 가격등급     │
└──────────────────┘  └──────────────────────┘
→ 각 모듈이 내부를 캡슐화하고 필요한 인터페이스만 노출
→ 지역 복잡성 억제, 새 기능 추가 공간 확보

6. 프랙털 기하학 — 자연의 복잡성 관리법

프랙털은 같은 패턴이 다른 규모로 반복되는 기하학적 구조다.

수학적 프랙털: - 만델브로 집합: z = z² + c 반복 → 어디를 확대해도 같은 패턴 - 시어핀스키 삼각형: 삼각형 안에 삼각형, 그 안에 또 삼각형 - 코흐 눈송이: 선분마다 삼각형 돌출 반복

자연의 프랙털: - 나무 가지: 줄기→가지→잔가지→같은 분기 패턴 반복 - 잎맥(엽맥) 네트워크: 큰 줄기→작은 줄기→더 작은 줄기 - 구름 형성: 어느 규모에서 보아도 같은 불규칙 패턴 - 은하 분포: 우주 전체가 필라멘트 구조의 자기 유사성

웨스트의 연구에 따르면 준선형 성장(규모의 경제)은 네트워크 기반 시스템에 내재된 프랙털 기하학의 직접적 결과다.

7. 프랙털 모듈성 — 소프트웨어의 자기 유사성 원리

소프트웨어를 네트워크 기반 시스템으로 볼 때: - 에너지 = 지식 - 파이프 = 모듈 인터페이스 - 최적화 = 균형 잡힌 결합

10장에서 정의한 균형 잡힌 결합이 소프트웨어의 자기 유사성 원리다.

7.1 통합 강도 4수준은 상대적이다

핵심 통찰: 한 수준의 통합 계약은 상위 수준에서 보면 구현 세부 정보(침입)가 된다.

# 객체 수준 — public 인터페이스 = 객체 층의 통합 계약
class PaymentService:
    def process(self, amount: int, currency: str) -> Receipt:
        self._validate(amount)       # ← private: 객체 내부 (침입 영역)
        self._call_gateway(amount)   # ← private: 객체 내부
        return Receipt(...)

# 서비스 수준에서는 PaymentService 전체가 "구현 세부"
# 외부 시스템은 REST 계약만 안다 (서비스 층의 통합 계약)
# POST /payments  { amount, currency }  → { receipt_id }

7.2 거리도 상대적이다

Python 표준 라이브러리의 datetime.date와 collections.Counter는 객체 수준에서 서로 멀리 떨어진 것으로 볼 수 있지만, 서비스 수준에서 보면 같은 마이크로서비스 내부에 있어 가깝다.

8. 결합 원리가 모든 층에 반복되는 구체 예

잘못된 예 — 메서드 수준에서 제어 결합

# 잘못된 예: calculate_price가 플래그(is_winter, is_vip)로 할인 로직을 직접 제어
def calculate_price(item, is_winter: bool, is_vip: bool):
    base = item.price
    if is_winter:
        base *= 0.8    # ← 계절 할인 세부 로직이 여기 노출
    if is_vip:
        base *= 0.9    # ← 등급 할인 세부 로직이 여기 노출
    return base
# 문제: 할인 종류 추가 시 is_* 플래그도 계속 늘어남 → 호출자가 내부 분기 제어

# 올바른 예: 각 메서드가 균형 잡힌 결합 — 의도만 노출
def apply_discount(item, discount_rate: float):
    """할인율을 적용한 가격 반환 (어떤 종류의 할인인지 모름)"""
    return item.price * (1 - discount_rate)

def get_discount_rate(customer_type: str, season: str) -> float:
    """고객 유형·시즌에 맞는 할인율 결정 (계산 로직 캡슐화)"""
    ...

# 호출자: apply_discount(item, get_discount_rate("vip", "winter"))
# 할인 종류 추가 시 apply_discount는 전혀 변경 불필요

잘못된 예 — 클래스 수준에서 스탬프 결합

# 잘못된 예: ReportService가 User 객체 전체를 받지만 email 필드 하나만 씀
class ReportService:
    def send_report(self, user: User, report: Report):
        self._email_client.send(
            to=user.email,     # ← email 하나만 쓰는데
            subject="월간 리포트",
            body=report.content
        )
# 문제: User에 새 필드 추가·구조 변경 시 ReportService가 잠재적으로 영향받음

# 올바른 예: 필요한 값만 받음 (데이터 결합)
class ReportService:
    def send_report(self, recipient_email: str, report: Report):
        self._email_client.send(
            to=recipient_email,
            subject="월간 리포트",
            body=report.content
        )
# User 객체 내부 구조가 어떻게 바뀌어도 영향 없음

잘못된 예 — 서비스 수준에서 공유 DB (콘텐츠 결합의 분산판)

잘못된 예:
OrderService ─────→ [공유 PostgreSQL — orders 테이블]
ReportService ────→ [공유 PostgreSQL — orders 테이블]
              (같은 테이블에 직접 SELECT/INSERT)

문제: OrderService가 컬럼명 변경 시 ReportService가 조용히 깨짐
     서비스 수준에서 다른 서비스의 "내부 DB 구조"를 침입 = 콘텐츠 결합

올바른 예:
OrderService ──→ [orders DB 단독 소유]
     ↓ REST API / 이벤트 (통합 계약만 공유)
ReportService ──────────────────→ (OrderService API 호출)

각 서비스가 DB를 캡슐화 → 서비스 수준 균형 잡힌 결합

같은 결합 원리, 다른 층 — 요약

층          나쁜 예 (침입·제어 결합)         좋은 예 (균형 결합)
───────────────────────────────────────────────────────────
문장        if is_winter and is_vip:          get_discount_rate() 호출
메서드      type/flag 파라미터로 내부 제어    의도별 메서드 분리
클래스      50개 필드 객체 전체 전달          필요한 값만 or DTO
모듈        모듈 내부 클래스 직접 import       모듈 공개 인터페이스만
서비스      다른 서비스 DB 직접 SELECT         REST/이벤트 계약

어느 층이든 "필요한 지식만 공유하라"는 원리는 동일하다.

9. 책임 할당 — 파나스의 통찰

데이비드 파나스(1971): "결국 모든 구조 조정은 책임 할당으로 귀결된다."

회사가 커지면 한 부서가 둘로 나뉘고, 각각 원래 책임의 일부를 맡는다. 소프트웨어도 같다 — WolfDesk가 모놀리스에서 4개 모듈로 나뉜 것이 정확히 이것. 각 모듈에 명확한 책임을 할당하고, 내부를 캡슐화하고, 필요한 인터페이스만 노출.

파나스 테스트: "이 모듈이 변경될 단 하나의 이유는 무엇인가?"

핵심 개념 정리

실무 체크리스트

• [ ] 새 기능 추가 시, 기존 경계 안에 쑤셔 넣기 전에 "새 추상화 계층이 필요한 시점인가?" 자문했나?
• [ ] 모듈/서비스 분리 결정 시 책임 할당이 명확한가? 파나스 테스트: "이 모듈이 변경될 단 하나의 이유가 뭔가?"
• [ ] 메서드 수준부터 서비스 수준까지 같은 층위 점검을 했나? 서비스 사이에서 "이건 침입 결합인가?" 묻는 것처럼 메서드 사이에서도 같은 질문을 했나?
• [ ] 마이크로서비스로 분리할 때 공유 DB를 제거했나? (콘텐츠 결합의 분산판 주의)
• [ ] 복잡성이 인지 한계를 언제 넘을지 인지하고 있나? n*(n-1)/2 속도로 증가한다.
• [ ] 통합 계약을 변경할 때, 그것이 상위 층에서 구현 세부 변경임을 인식하고 하위 호환성을 고려했나?
• [ ] 메서드에 boolean/enum 파라미터를 추가하려고 할 때 "제어 결합"이 아닌지 검토했나?
• [ ] 새 구성요소를 추가할 때 n*(n-1)/2 법칙으로 상호작용 증가를 추정했나?

연습문제 (문제만 — 정답은 부록 D)

1. 개념. 소프트웨어 시스템의 구성요소가 n개일 때 가능한 상호작용의 수를 수식으로 표현하라. 구성요소가 5개일 때와 10개일 때의 상호작용 수를 계산하고, 어떤 성장 역학인지 설명하라.

2. 비유. 도시의 철골 고층빌딩 도입을 소프트웨어 설계의 어떤 혁신에 대응시킬 수 있는가? 갈릴레오의 두 혁신 방법 중 어느 것에 해당하는지 구분하고, 대응되는 소프트웨어 예를 들어라.

3. 자기 유사성 분석. 다음 시나리오에서 서비스 수준, 모듈 수준, 메서드 수준에서 각각 어떤 결합 문제가 반복되는지 분석하라. — "주문 서비스의 OrderController가 직접 DB를 호출하고, 그 DB를 정산 서비스도 직접 읽으며, OrderController 메서드 안에서 if(type == 'normal') ... else if(type == 'vip') ... 분기가 5개 이상 있다."

4. 설계. WolfDesk v1 → v2 추상화 도입처럼 다음 시스템을 모듈로 분리하라. — "전자상거래 모놀리스에 사용자 관리, 상품 카탈로그, 주문 처리, 결제, 배송 추적, 리뷰·평점이 모두 한 네임스페이스에 있다." 분리 기준(책임)을 명시하라.

5. 적용. 통합 강도의 상대성을 실제 사례에 적용하라 — Python datetime 라이브러리의 date.today() 메서드는 어떤 추상화 층에서 "통합 계약"이고, 어떤 층에서 "구현 세부"인가? 두 층을 구체적으로 명시하라.

최신 동향 (검증 2026-05-21)

• 모듈러 모놀리스(Modular Monolith)의 재평가 — 균형 잡힌 결합 원리를 모든 추상화 층에 일관 적용하는 흐름이 가속 중이다. Modular Monolith 패턴이 마이크로서비스와 모놀리스 사이 선택지로 주목받으며, 프랙털 모듈성을 서비스 분리 없이 구현하는 현실적 대안으로 인정받고 있다.
• 플랫폼 엔지니어링(Platform Engineering)의 부상 — 추상화 계층을 사람이 직접 도입하는 대신, 내부 개발 플랫폼(IDP)이 공통 인터페이스 계층(Backstage, Crossplane 등)을 자동으로 제공해 성장 한계를 시스템적으로 높이는 접근이 확산 중이다.
• AI 지원 복잡성 관리 — AI 도구가 코드 의존성 시각화, 자동 리팩터링 제안 등으로 복잡성 탐지를 보조하기 시작했다. 그러나 갈릴레오의 "더 강한 재료" 단계(AI가 인지 한계를 완전히 대체)에는 아직 도달하지 못했다.

부록 A. 용어 사전

부록 B. 핵심 비교표

성장 역학 비교

프랙털 결합 원리 — 층별 적용 비교

갈릴레오 법칙의 소프트웨어 적용

통합 강도 상대성 — 층별 관점 비교

부록 C. 추천 참고 자료 & 링크

Tier 1 공식·표준 (생존 확인 2026-05-21)

책 다른 장 안내

부록 D. 연습문제 풀이

1. (상호작용 수 = n*(n-1)/2 — 초선형)

구성요소가 n개일 때 모든 쌍의 수 = n(n-1)/2. - n=5: 54/2 = 10개 - n=10: 109/2 = 45*개

구성요소 2배(5→10) → 상호작용 4.5배(10→45). 이것이 초선형 성장. 인지 부하는 이 속도로 증가하는데 인간 인지 한계는 정적 → 어느 순간 복잡성이 인지 한계를 넘어 "큰 진흙덩이"가 된다.

2. (철골 고층빌딩 = 형태 변경 = 추상화 계층 도입)

갈릴레오의 두 번째 혁신 방법(형태 변경)에 해당. 건물이 커지자 수평 확장의 한계에 부딪혔고, 철골 수직 구조라는 새 추상화로 같은 면적에 더 많은 공간을 만들었다. 소프트웨어 대응: 모놀리스가 한 네임스페이스의 한계에 도달하자, 모듈/서비스 계층이라는 새 추상화를 도입해 같은 코드베이스에 더 많은 기능을 담을 수 있게 됨. 예: WolfDesk v1 → v2 (4개 모듈 도입).

3. (자기 유사적 결합 문제 — 세 층 모두 같은 패턴)

• 서비스 수준: 정산 서비스가 주문 서비스의 DB를 직접 읽음 = 콘텐츠 결합 (침입).
• 모듈 수준: OrderController가 DB를 직접 호출 = 컨트롤러가 저장 구현 세부를 앎 = 콘텐츠 결합 (모듈 내부 침입).
• 메서드 수준: if(type == 'normal') ... else if(type == 'vip') ... = 제어 결합 (내부 분기를 호출자가 결정).

세 층 모두 "필요 이상의 지식을 공유하는 강한 결합"이라는 동일한 원리로 진단된다 — 프랙털 자기 유사성.

4. (책임 할당 기준 모듈 분리)

[ UserManagement ]  — 회원 등록·인증·권한 (신원과 액세스)
[ ProductCatalog ]  — 상품 정보·카테고리·재고 (상품 도메인)
[ OrderProcessing ] — 주문 생성·상태 관리 (주문 수명주기)
[ Payment ]         — 결제 처리·환불 (금융 트랜잭션)
[ ShippingTracking ]— 배송지·추적·완료 (물류 도메인)
[ ReviewRating ]    — 리뷰 작성·평점 집계 (피드백 도메인)

각 모듈은 자신의 DB를 소유하고, 다른 모듈과는 명시적 계약(API·이벤트)으로만 통신. 파나스 원칙: 각 모듈에 "변경될 단 하나의 이유"가 있어야 한다.

5. (통합 강도의 상대성 — datetime.date.today())

• 메서드/클래스 수준(통합 계약): 내 코드에서 date.today()를 호출할 때, 이것은 Python datetime 모듈이 나에게 제공하는 공개 인터페이스 = 통합 계약. 나는 반환 타입(date)과 시그니처만 알면 됨.
• 서비스/시스템 수준(구현 세부): 내 애플리케이션 서비스를 외부 시스템이 볼 때, date.today() 사용 여부는 내 서비스의 내부 구현 세부. 외부 시스템은 내 REST API 계약만 보고, 내가 datetime을 쓰는지 arrow 라이브러리를 쓰는지 모른다. 즉 같은 메서드 호출이 층에 따라 "통합 계약"이기도 하고 "구현 세부"이기도 하다.